Parameterized cells (pcells) have been used for more than twenty years in designing full custom chip designs. The pcells are evaluated every time the design is opened. The highly dynamic nature of pcells introduces a level of variability that the design teams may want to control.
Over the years, the use of pcells has shown three main drawbacks. The first drawback is long design opening time. Designs containing pcells are often slow to open as the code within the pcells are evaluated in order to produce the pcell design data. The second drawback is the lack of read-interoperability of the pcells. When the pcell code is written in some proprietary language such as SKILL, third party application not linking the right pcell evaluator can not evaluate the pcells, and can thus not have access to the pcell design data. The third drawback is the lack of write-interoperability of the pcells. Third party applications have difficulty correctly editing a design containing non-evaluated pcells.
Several solutions have been proposed to partially address some of these drawbacks. The first solution is to translate the design into a fully evaluated, tool neutral representation, for example GDSII. The second solution is to create a complete copy of the design. Within that copy, remaster all instances of pcell into instances of a regular cell (e.g., the regular cell being a copy of the pcell instance sub-master). This process is also known as “freezing” the design. A variant of that solution replaces the sub-masters in place with a saved version of the pcell parameters, to enable later “thawing” of the design. A third solution is provided by CiraNova of Santa Clara, Calif. It provides a low performance cache from external observation of the behavior of the third party application in that environment. For example, in the Virtuoso environment, it replaces all SKILL pcell instances as CiraNova pcell instances. The CiraNova pcell plug-in role is to cache on disk evaluated pcell and to re-use those from disk. The evaluation is done by invoking a sub-process, e.g., a DFII subprocess, to evaluate one pcell sub-master at a time, to store it on disk as a regular master in a temporary lib/cell/view, then to copy the layout file within a cache. The re-use is done by populating the cached regular master to a temporary lib/cell/view, to open that lib/cell/view and to copy the design data from that lib/cell/view to pcell sub-master created by a system such as OpenAccess (available from www.si2.org) when evaluating a pcell with a new set of parameters.
However, none of these solutions fully or adequately solves the aforementioned problems. Therefore, there is a need for an improved approach for implementing pcells.